Generally, in a database system, a client and a server frequently communicate with each other using TCP/IP protocol. For example, a database server instance may host multiple coordinating processes or threads, which accept database client requests on a pre-configured TCP/IP port. Multiple coordinating processes or threads share the transactions to be carried out on behalf of a database client request and work interchangeably. In this context, the term database server instance corresponds to one or more database server processes. However, this configuration generates excessive overhead and contention in a two-tier deployment, where multiple clients and multiple database server instances reside on the same physical computing device.
Some conventional systems attempt to alleviate the TCP/IP contention by using separate TCP/IP ports for every database server instance and/or alleviate the TCP/IP overhead by implementing Inter Process Communication (IPC) mechanism (e.g., UNIX domain sockets) for communication with every database server instance. Nevertheless, such conventional systems do not scale up well and do not meet latency requirements laid down by widely published benchmarks. The problems are exacerbated in systems with a Non-Uniform Memory Access (NUMA) architecture, where the memory access time depends on the location of the shared memory segment relative to a processor. As a result, database clients as well as database server instances running on a NUMA node other than the one on which the single shared memory segment resides typically will frequently encounter higher memory access latencies.
Accordingly, conventional systems fail to provide a communication mechanism with ideal performance and scalability, especially when clients and database server instances are deployed on the same physical computing device.